【初心者向け】Session Manager でインスタンスが表示されない時のトラブルシュート

AWS Systems Manager の Session Manager の初期設定は、誰もが一度はハマるやつなのではないでしょうか？

#Amazon EC2

#AWS Systems Manager Session Manager

#AWS Systems Manager（SSM）

#AWS

ちゃだいん

2020.08.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ちゃだいん（@chazuke4649）です。

Session Manager の初期設定って、よくつまりませんか？私はよくつまります。

今日は先日久しぶりにさわったところ、やはりつまったので、次つまった時のためにメモを残しておこうと思います。そして、Well-Architected Flameworkにならい、質問形式で未来の自分へチェックすべきポイントを投げかけてみます。

参考URL

1. EC2インスタンス / エージェントが原因

いくつかのカテゴリに分けてみました。最初は、EC2インスタンス周りや、その中に起動している SSM エージェントに関してです。

IAMロールが不適切ではありませんか？

基本的には、対象のEC2インスタンスにアタッチされているIAMロールに、IAMポリシーのマネージドポリシーであるAmazonSSMManagedInstanceCoreがアタッチされていればOKです。

その他 SSM の他の機能も使いたい場合は、必要に応じて以下を参照しIAMポリシーを追加します。

Step 4: Create an IAM instance profile for Systems Manager - AWS Systems Manager

これはただの個人の所感ですが、IAMロールをつけ忘れていた場合に、IAMロールをアタッチしてもすぐにSSMコンソールで表示されないことがあります。早く確認したいときは、インスタンスを再起動すると、SSM側に認識されやすくなることがあります。

SSM エージェントはインストールされていますか？あるいはバージョンが古い可能性はありませんか？

例えば、既存の古いWindowsインスタンスで新たにSession Managerを使いたいなどの場合は要注意です。

SSM エージェントは、Systems Manager で使用する各インスタンスにインストールする必要があります。SSM エージェントは、デフォルトで、次の Amazon マシンイメージ (AMI) から作成されたインスタンスに事前インストールされています。

2016 年 11 月以降に公開された Windows Server 2008-2012 R2 AMI
Windows Server 2016 および 2019
Amazon Linux
Amazon Linux 2
Ubuntu Server 16.04
Ubuntu Server 18.04
Amazon ECS 最適化

About SSM エージェント - AWS Systems Manager

そもそも最初からエージェントが入っていないAMIではありませんか？

CentOSやRHEL,SUSEなどのLinuxOSではデフォルトではインストールされていません。

上記ドキュメントの後半を参照ください。Linux と Windows のエージェントインストールについては以下よりどうぞ。

Installing and configuring SSM エージェント on Windows Server instances - AWS Systems Manager

Installing and configuring SSM エージェント on EC2 instances for Linux - AWS Systems Manager

2. ネットワークが原因（インターネットアクセス編）

アウトバウンドのインターネットアクセスが禁止されていませんか？

プライベートサブネットのEC2インスタンスの場合は、ネットワークが原因でうまくいかないことがよくあります。以下の各ネットワークコンポーネントを調査します。アウトバウンドのインターネットアクセスがそのまま出られるのか、NATを経由するのかで確認方法は異なります。

セキュリティグループ

アウトバウンド通信で443ポートがパブリックエンドポイントであるSSM エンドポイント（＝インターネットアクセス）へ通信可能な状態かどうか確認します。

ネットワークACL（NACL）

セキュリティグループと同じ観点で確認します。

ルートテーブル

パブリックサブネットの場合：　インターネットゲートウェイをターゲットとしたデフォルトルートが設定されているか確認します。
プライベートサブネットの場合：　インスタンスが配置されているサブネットでは、デフォルトルートのターゲットがNATになっており、パブリックサブネットでは、デフォルトルートがインターネットゲートウェイが設定されてるか確認します。(NATゲートウェイは下図参照)

引用元： NAT ゲートウェイ - Amazon Virtual Private Cloud

NAT Gateway or Internet Gateway

パブリックサブネットの場合：　VPCにインターネットゲートウェイがアタッチされているか確認します。
プライベートサブネットの場合：　パブリックサブネット側にNATゲートウェイが配置されていて、VPCにインターネットゲートウェイがアタッチされているか確認します。（先ほどの上図参照）

※NATゲートウェイを使用する場合、間違えてNATゲートウェイをプライベートサブネットに配置しているパターンはあるあるです。

3. ネットワークが原因（VPCエンドポイント編）

必要なVPCエンドポイントがないことはないですか？

この記事にわかりやすく書かれていますが、Session　Managerの場合だと以下4つのVPCエンドポイントが必要となります。

com.amazonaws.region.ssm
com.amazonaws.region.ec2messages
com.amazonaws.region.ssmmessages
com.amazonaws.region.s3

Step 6: (Optional) Create a Virtual Private Cloud endpoint - AWS Systems Manager

上3つインターフェース型エンドポイントは、セキュリティグループ大丈夫？

インターフェース型エンドポイントは、セキュリティグループが割り当てられます。これがデフォルトのままだと、EC2インスタンスからの443ポートの通信を許可してない可能性があります。

最後の1つのゲートウェイ型エンドポイントは、ルートテーブル大丈夫？

S3のVPCエンドポイントを使用するには、ルートテーブルにターゲットとして追加する必要があります。ここが漏れてないかも確認します。

4. ネットワークが原因（インターネットとVPCエンドポイント両方ある編）

インターネットアクセスとVPCエンドポイントがある場合、VPCエンドポイントが優先されます

両方ある場合は、VPCエンドポイントが優先されるので、「インターネットアクセスの経路は問題ないのに...」という場合は、実はVPCエンドポイントが設定されている、かつ設定に不備があるという可能性を疑ってみてください。インターフェース型VPCエンドポイントによるネットワーク経路の変化、仕組みなどは下図および公式ドキュメントを参考ください。